What changes were proposed in this pull request?

Three bugs blocked the full LDAPS setup flow end-to-end on Ambari 3.0
(Python 3, Java 9+):

1. serverUtils.py — Encode POST body to bytes in
   perform_changes_via_rest_api(). Python 3's urllib requires bytes
   for request.data; json.dumps() returns a str, causing
   ambari-server setup-ldap to fail with TypeError: POST data should be bytes, an iterable of bytes, or a file object. It cannot be of type str. while saving LDAP configuration.

2. setupSecurity.py — Same encoding fix applied to both POST bodies in
   sync_ldap(). Fixes the identical POST data should be bytes error
   during ambari-server sync-ldap --all, which occurs in a separate code
   path from (1) and was not covered by the existing AMBARI-26062 fix
   (which only patched configs.py).

3. ambari-env.sh — Added
   --add-opens java.naming/com.sun.jndi.ldap=ALL-UNNAMED to
   AMBARI_JVM_ARGS. On Java 9+, the module system blocks Spring LDAP's
   reflective access to the JDK-internal class
   com.sun.jndi.ldap.LdapCtxFactory, causing
   IllegalAccessError/NoClassDefFoundError on every LDAP login attempt
   via the Ambari UI. Ambari's default JVM args already open several
   java.base packages for the same reason; java.naming was missing.

Also updated 8 sync_ldap-related unit test assertions in
TestAmbariServer.py to expect bytes instead of str, keeping the test
suite consistent with fix (2).

Together these three fixes unblock ambari-server setup-ldap,
ambari-server sync-ldap --all, and LDAP authentication via the Ambari
UI, which were all broken on a fresh Ambari 3.0 install running Python 3
and Java 9+.

How was this patch tested?

• Unit tests: Updated and ran the 8 affected sync_ldap assertions in
  TestAmbariServer.py to assert bytes request bodies; full test module
  passes after the change.
• Manual end-to-end test on a live Ambari 3.0.0 install (Python 3.6,
  Java 17) against an OpenLDAP server:
  1. Ran ambari-server setup-ldap -v with SSL enabled — configuration
     now saves successfully (previously failed with the TypeError
     above).
  2. Ran ambari-server sync-ldap --all — sync now completes
     successfully, confirmed by summary output showing groups/users
     created (previously failed with the sync event creation error).
  3. Logged in to the Ambari UI as a synced LDAP user — authentication
     now succeeds (previously failed with the Java IllegalAccessError /
     NoClassDefFoundError in ambari-server.log).
• Verified no regression to non-LDAP flows: existing (non-LDAP)
  perform_changes_via_rest_api() callers continue to work, since the fix
  only changes how the body is encoded, not the request logic itself.